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Resource ReSerVation Protocol (RSVP) -- 
Version 1 Message Processing Rules 


Status of this Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Abstract 
This memo contains an algorithmic description of the rules used by an 


RSVP implementation for processing messages. It is intended to 
clarify the version 1 RSVP protocol specification. 


This memo provides a generic description of the rules for the 
operation of Version 1 of RSVP [RFC 2205]. It is intended to outline 
a set of algorithms that will accomplish the needed function, 
omitting many details. 


1. GENERIC DATA STRUCTURES 


This memo assumes the generic interface calls defined in [RFC 2005] 
and the following data structures. An actual implementation may use 
additional or different data structures and interfaces. The data 
structure fields that are shown are required unless they are 
explicitly labelled as optional. 


o PSB -- Path State Block 
Each PSB holds path state for a particular (session, sender) 


pair, defined by SESSION and SENDER TEMPLATE objects, 
respectively, received in a PATH message. 
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PSB contents include the following values from a PATH message: 
= Session 

= Sender_Template 

= Sender_Tspec 


= The previous hop IP address and the Logical Interface 
Handle (LIH) from a PHOP object 


- The remaining IP TIL 
= POLICY_DATA and/or ADSPEC objects (optional) 
= Non_RSVP flag 


- E Police flag 


Local Only flag 


In addition, the PSB contains the following information provided 
by routing: OutInterface list, which is the list of outgoing 
interfaces for this (sender, destination), and IncInterface, 
which is the expected incoming interface. For a unicast 
destination, QutInterface list contains one entry and 
IncInterface is undefined. 


Note that there may be more than one PSB for the same (session, 
sender) pair but different incoming interfaces. At most one of 
these, which will have the Local_Only flag off, will be the PSB 
used for forwarding PATH messages downstream; we will refer to 
it as the "forwarding PSB" in the following. The other PSB’s 
will have the Local_Only flag on and an empty 
OutInterface_list.h The Local_Only flag is needed to correctly 
match PSB’s against RSB’s, by the rules of [RFC 2205]. 


o RSB -- Reservation State Block 


Fach RSB holds a reservation request that arrived in a 
particular RESV message, corresponding to the triple: (session, 
next hop, Filter spec list). Here "Filter spec list" may be a 
list of FILTER SPECs (for SE style), a single FILTER SPEC (FF 
style), or empty (WF style). We define the virtual object type 
"FILTER_SPEC*" for such a data structure. 
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RSB contents include: 

- Session specification 
= Next hop IP address 

- Filter spec list 


= The outgoing (logical) interface OI on which the 
reservation is to be made or has been made. 


- Style 
= Flowspec 
= A SCOPE object (optional, depending upon style) 
- RESV CONFIRM object that was received (optional) 

o TCSB -- Traffic Control State Block 
Fach TCSB holds the reservation specification that has been 
handed to traffic control for a specific outgoing interface. In 
general, TCSB information is derived from RSB's for the same 
outgoing interface. Each TCSB defines a single reservation for 


a particular triple: (session, OI, Filter_spec_list). TCSB 
contents include: 


= Session 

- OI (Outgoing Interface) 

- Filter spec list 

= TC_Flowspec, the effective flowspec, i.e., the LUB over the 
corresponding FLOWSPEC values from matching RSB’s. 
TC_Flowspec is passed to traffic control to make the actual 


reservation. 


- Fwd Flowspec, the updated object to be forwarded 
after merging. 


= TC_Tspec, equal to Path_Te, the effective sender Tspec. 
- Police Flags 


The flags are E Police Flag, M Police Flag, and 
B Police Flag. 
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a Rhandle, F_Handle_list 


Handles returned by the traffic control interface, 
corresponding to a flowspec and perhaps a list of filter 
specs. 


7 A RESV_CONFIRM object to be forwarded. 
o BSB -- Blockade State Block 


Each BSB contains an element of blockade state. Depending upon 
the reservation style in use, the BSB's may be per (session, 
sender template) pair or per (session, PHOP) pair. In practice, 
an implementation might embed a BSB within a PSB; however, for 
clarity we describe BSB’s independently. 


The contents of a BSB include: 


Session 


- Sender Template (which is also a filter spec) 


PHOP 


FLOWSPEC Qb 


Blockade timer Tb 


The following Boolean Flag variables are used in this section: 
Path Refresh Needed, Resv Refresh Needed, Tear Needed, 

Need Scope, B Merge, and NeworMod. Refresh PHOP list is a 
variable-length list of PHOPs to be refreshed. 


2. PROCESSING RULES 
MESSAGE ARRIVES 


Verify version number and RSVP checksum, and discard message if any 
mismatch is found. 


If the message type is not PATH or PTEAR or RACK and if the IP 
destination address does not match any of the addresses of the local 
interfaces, then forward the message to IP destination address and 
return. 


Parse the sequence of objects in the message. If any required 
objects are missing or the length field of the common header does not 
match an object boundary, discard the message and return. 
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Verify the INTEGRITY object, if any. If the check fails, discard the 
message and return. 


Verify the consistent use of port fields. If the DstPort in the 
SESSION object is zero but the SrcPort in a SENDER TEMPLATE or 
FILTER SPEC object is non-zero, then the message has a "conflicting 
source port" error, silently discard the message and return. 


Processing of POLICY DATA objects will be specified in the future. 
Further processing depends upon message type. 
PATH MESSAGE ARRIVES 


Assume the PATH message arrives on interface InIf. 


Process the sender descriptor object sequence in the message as 
follows. The Path Refresh Needed and Resv Refresh Needed flags are 
initially off. 


o Search for a path state block (PSB) whose (session, 
sender template) pair matches the corresponding objects in the 
message, and whose IncInterface matches InIf. 


During this search: 


T; If a PSB is found whose session matches the 
DestAddress and Protocol Id fields of the received 
SESSION object, but the DstPorts differ and one is 
zero, then build and send a "Conflicting Dst Port" 
PERR message, drop the PATH message, and return. 


2. If a PSB is found with a matching sender host but the 
Src Ports differ and one of the SrcPorts is zero, then 
build and send an "Ambiguous Path" PERR message, drop 
the PATH message, and return. 


3. If a forwarding PSB is found, i.e., a PSB that matches 
the (session, sender_template) pair and whose 
Local_Only flag is off, save a pointer to it in the 
variable fPSB. If none is found, set fPSB to NULL. 


o If there was no matching PSB, then: 
Eg Create a new PSB. 
2x Copy contents of the SESSION, SENDER_TEMPLATE, 


SENDER_TSPEC, and PHOP (IP address and LIH) objects 
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into the PSB. 


If the sender is from the local API, set 

Out Interface List to the single interface whose 
address matches the sender address, and make 
IncInterface undefined. Otherwise, turn on the 
Local_Only flag. 


Turn on the Path_Refresh_Needed flag. 


o Otherwise (there is a matching PSB): 


If the PHOP IP address, the LIH, or Sender Tspec 
differs between the message and the PSB, copy the new 
value into the PSB and turn on the Path Refresh Needed 
flag. If the PHOP IP address or the LIH differ, also 
turn on the Resv_Refresh_Needed flag. 


o Call the resulting PSB the "current PSB" (cPSB). Update 
the cPSB, as follows: 


Start or Restart the cleanup timer for the PSB. 


If the message contains an ADSPEC object, copy it into 
the PSB. 


Copy E Police flag from SESSION object into PSB. 
Store the received TTL into the PSB. 


If the received TTL differs from Send_TTL in the RSVP 
common header, set the Non_RSVP flag on in the PSB. 


o If the PSB is new or if there is no route change 
notification in place, then perform the following routing 
manipulations, but not if the cPSB is from the local API. 


I 
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Invoke the appropriate Route_Query routine using 
DestAddress from SESSION and (for multicast routing) 
SrcAddress from Sender_Template. 


Call the results (Rt_OutL, Rt InIf). 

If the destination is multicast and Rt_InIf differs 
from IncInterface in the cPSB, but fPSB points to the 
cPSB, then do the following. 


- Turn on the Local Only flag and clear the 
Out Interface list of the fPSB. Set the fPSB 
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pointer to NULL. 


z Search for a PSB for the same (session, 
sender_template) pair whose IncInterface matches 
Rt_InIf. If one is found, set fPSB to point to 
it. 


If the destination is multicast and Rt_InIf is the 
same as IncInterface in the cPSB, but fPSB does not 
point to the cPSB, then do the following. 


- Copy into the cPSB the QutInterface list from the 
PSB, if any, pointed to by fPSB. Clear 
OutInterface list and turn on the Local Only flag 
in the PSB pointed to by fPSB, if any. 


- Turn off the Local Only flag in the cPSB and set 
fPSB to point to cPSB. 


If Rt OutL differs from OutInterface list of the PSB 
pointed to by fPSB, then: 


= Update the OutInterface_list of the PSB from 
Rt_OutL, and then execute the PATH LOCAL REPAIR 
event sequence below. 


o If the Path Refresh Needed flag is now off, drop the PATH 
message and return. 


Otherwise (the path state is new or modified), do 
refreshes, upcalls, and state updates as follows. 


De 
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If this PATH message came from a network interface and 
not from a local application, make a Path Event upcall 
for each local application for this session: 


Call: <Upcall_Proc>( session-id, PATH EVENT, 
flags, sender tspec, sender template 
[ , ADSPEC] [ , POLICY DATA] ) 


If OutInterface list is not empty, execute the PATH 
REFRESH event sequence (below) for the sender defined 
by the PSB. 


Search for any matching reservation state, i.e., an 
RSB whose Filter spec list includes a FILTER SPEC 
matching the SENDER TEMPLATE and whose OI appears in 
the OutInterface list, and make this the ‘active RSB’. 
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If none is found, drop the PATH message and return. 


4. Execute the RESV REFRESH sequence (below) for the PHOP 
in the PSB. 
Dis Execute the event sequence UPDATE TRAFFIC CONTROL to 


update the local traffic control state if necessary. 
This sequence will turn on the Resv Refresh Needed 
flag if the traffic control state has been modified in 
a manner that should trigger a reservation refresh. 

If so, execute the RESV REFRESH sequence for the PHOP 
in the PSB. 


Drop the PATH message and return. 


PTEAR MESSAGE ARRIVES 


o 


Search for a PSB whose (Session, Sender Template) pair 
matches the corresponding objects in the message. If no 
matching PSB is found, drop the PTEAR message and return. 


Forward a copy of the PTEAR message to each outgoing 
interface listed in OutInterface list of the PSB. 


Find each RSB that matches this PSB, i.e., whose 
Filter_spec_list matches Sender_Template in the PSB and 
whose OI is included in OutInterface_list. 


T; If the RSB style is explicit, then: 
= Delete from Filter_spec_list the FILTER_SPEC that 
matches the PSB. 
- if Filter spec list is now empty, delete the RSB. 
2. Otherwise (RSB style is wildcard) then: 


= If this RSB matches no other PSB, then delete the 
RSB. 


3. If an RSB was found, execute the event sequence UPDATE 
TRAFFIC CONTROL (below) to update the traffic control 
state to be consistent with the current reservation 
and path state. 


Delete the PSB. 


Drop the PTEAR message and return. 
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PERR MESSAGE ARRIVES 


(0) Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair 
matches the corresponding objects in the message. If no 
matching PSB is found, drop the PERR message and return. 


o If the previous hop address in the PSB is the local API, 
make an error upcall to the application: 


Call: <Upcall_Proc>( session-id, PATH ERROR, 
Error code, Error value, Node Addr, 
Sender Template [ , Policy Data] ) 


Any SENDER TSPEC or ADSPEC object in the message is 
ignored. 


Otherwise, send a copy of the PERR message to the PHOP IP 
address. 


o Drop the PERR message and return. 
RESV MESSAGE ARRIVES 


Initially, Refresh PHOP list is empty and the 
Resv Refresh Needed and NeworMod flags are off. These variables 
are used to control immediate reservation refreshes. 


o Determine the Outgoing Interface OI 


The logical outgoing interface OI is taken from the LIH in 
the NHOP object. (If the physical interface is not implied 
by the LIH, it can be learned from the interface matching 
the IP destination address). 


o Check the path state 


des If there are no existing PSB’s for SESSION then build 
and send a RERR message (as described later) 
specifying "No path information", drop the RESV 
message, and return. 


2% If a PSB is found with a matching sender host but the 
SrcPorts differ and one of the SrcPorts is zero, then 
build and send an "Ambiguous Path" PERR message, drop 
the RESV message, and return. 
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o Check for incompatible styles. 


If any existing RSB for the session has a style that is 
incompatible with the style of the message, build and send 
a RERR message specifying "Conflicting Style", drop the 
RESV message, and return. 


Process the flow descriptor list to make reservations, as 
follows, depending upon the style. The following uses a filter 
spec list struct Filtss of type FILTER SPEC” (defined earlier). 


For FF style: execute the following steps independently for each 
flow descriptor in the message, i.e., for each (FLOWSPEC, 
Filtss) pair. Here the structure Filtss consists of the 

FILTER SPEC from the flow descriptor. 


For SE style, execute the following steps once for (FLOWSPEC, 
Filtss), with Filtss consisting of the list of FILTER SPEC 
objects from the flow descriptor. 


For WF style, execute the following steps once for (FLOWSPEC, 
Filtss), with Filtss an empty list. 


o Check the path state, as follows. 


1s Locate the set of PSBs (senders) that route to OI and 
whose SENDER TEMPLATEs match a FILTER SPEC in Filtss. 


If this set is empty, build and send an error message 
specifying "No sender information", and continue with 
the next flow descriptor in the RESV message. 


2. If the style has explicit sender selection (e.g., FF 
or SE) and if any FILTER_SPEC included in Filtss 
matches more than one PSB, build and send a RERR 
message specifying "Ambiguous filter spec" and 
continue with the next flow descriptor in the RESV 


message. 

3s If the style is SE and if some FILTER_SPEC included in 
Filtss matches no PSB, delete that FILTER_SPEC from 
Filtss. 

4. Add the PHOP from the PSB to Refresh_PHOP_list, if the 


PHOP is not already on the list. 
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Find or create a reservation state block (RSB) for 
(SESSION, NHOP). If the style is distinct, Filtss is also 
used in the selection. Call this the "active RSB". 


If the active RSB is new: 


Ts Set the session, NHOP, OI and style of the RSB from 
the message. 


2x Copy Filtss into the Filter_spec_list of the RSB. 


3. Copy the FLOWSPEC and any SCOPE object from the 
message into the RSB. 


4. Set NeworMod flag on. 


If the active RSB is not new, check whether Filtss from the 
message contains FILTER_SPECs that are not in the RSB; if 
so, add the new FILTER_SPECs and turn on the NeworMod flag. 


Start or restart the cleanup timer on the active RSB, or, 
in the case of SE style, on each FILTER_SPEC of the RSB 
that also appears in Filtss. 


If the active RSB is not new, check whether STYLE, FLOWSPEC 
or SCOPE objects have changed; if so, copy changed object 
into RSB and turn on the NeworMod flag. 


If the message contained a RESV_CONFIRM object, copy it 
into the RSB and turn on NeworMod flag. 


If the NeworMod flag is off, continue with the next flow 
descriptor in the RESV message, if any. 


Otherwise (the NeworMod flag is on, i.e., the active RSB is 
new or modified), execute the UPDATE TRAFFIC CONTROL event 
sequence (below). If the result is to modify the traffic 
control state, this sequence will turn on the 
Resv_Refresh_Needed flag and make a RESV_EVENT upcall to 
any local application. 


If the UPDATE TRAFFIC CONTROL sequence fails with an error, 
then delete a new RSB but restore the original reservation 
in an old RSB. 


Continue with the next flow descriptor. 
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When all flow descriptors have been processed, check the 
Resv_Refresh_Needed flag. If it is now on, execute the 
RESV REFRESH sequence (below) for each PHOP in 
Refresh_PHOP_list. 


Drop the RESV message and return. 


If processing a RESV message finds an error, a RERR message 
is created containing flow descriptor and an ERRORS object. 
The Error Node field of the ERRORS object is set to the IP 

address of OI, and the message is sent unicast to NHOP. 


RTEAR MESSAGE ARRIVES 


Processing of a RTEAR message roughly parallels the processing 
of the corresponding RESV message 


A RTEAR message arrives with an IP destination address matching 
outgoing interface OI. Flag Resv_Refresh_Needed is initially 
off and Refresh_PHOP_list is empty. 


o 


Determine the Outgoing Interface OI 


The logical outgoing interface OI is taken from the LIH in 
the NHOP object. (If the physical interface is not implied 
by the LIH, it can be learned from the interface matching 
the IP destination address). 


Process the flow descriptor list in the RTEAR message to 
tear down local reservation state, as follows, depending 
upon the style. The following uses a filter spec list 
struct Filtss of type FILTER_SPEC* (defined earlier). 


For FF style: execute the following steps independently for 
each flow descriptor in the message, i.e., for each 
(FLOWSPEC, Filtss) pair. Here the structure Filtss 
consists of the FILTER_SPEC from the flow descriptor. 


For SE style, execute the following steps once for 
(FLOWSPEC, Filtss), with Filtss consisting of the list of 
FILTER_SPEC objects from the flow descriptor. 


For WF style, execute the following steps once for 
(FLOWSPEC, Filtss), with Filtss an empty list. 
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Find an RSB matching (SESSION, NHOP). If the style is 
distinct, Filtss is also used in the selection. Call 
this the "active RSB". If no active RSB is found, 
continue with next flow descriptor. 


Check the style 


If the active RSB has a style that is incompatible 
with the style of the message, drop the RTEAR message 
and return. 


Delete from the active RSB each FILTER_SPEC that 
matches a FILTER_SPEC in Filtss. 


If all FILTER SPECs have now been deleted from the 
active RSB, delete the active RSB. 


Execute the UPDATE TRAFFIC CONTROL event sequence 
(below) to update the traffic control state to be 
consistent with the reservation state. If the result 
is to modify the traffic control state, the 
Resv_Refresh_Needed flag will be turned on anda 
RESV_EVENT upcall will be made to any local 
application. 


Continue with the next flow descriptor. 


o All flow descriptors have been processed. 


Build and send any RTEAR messages to be forwarded, in the 
following manner. 


Ies 
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Select each PSB that routes to the outgoing interface 
OI, and, for distinct style, that has a 
SENDER_TEMPLATE matching Filtss. 


Select a flow descriptor (Qj,Fj) (where Fj may be a 
list) in the RTEAR message whose FILTER_SPEC matches 
the SENDER_TEMPLATE in the PSB. If not match is 
found, return for next PSB. 


- Search for an RSB (for any outgoing interface) to 
which the PSB routes and whose Filter spec list 
includes the SENDER TEMPLATE from the PSB. 


= If an RSB is found, add the PHOP of the PSB to 
the Refresh_PHOP_list. 
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= Otherwise (no RSB is found), add the flow 
descriptor (Qj,Fj) to the new RTEAR message being 
built, in a manner appropriate to the style. 


- Continue with the next PSB. 


3g If the next PSB is for a different PHOP or the last 
PSB has been processed, forward any RTEAR message that 
has been built. 


If any PSB's were found in the preceding step, and if the 
Resv. Refresh Needed flag is now on, execute the RESV 
REFRESH sequence (below) for each PHOP in 
Refresh PHOP list. 


Drop the RTEAR message and return. 


RERR MESSAGE ARRIVES 


A RERR message arrives through the (real) incoming interface 
Int. 


o 


If there is no path state for SESSION, drop the RERR 
message and return. 


If the Error Code = 01 (Admission Control failure), do 
special processing as follows: 


Tz Find or create a Blockade State Block (BSB), in the 
following style-dependent manner. 


For WF (wildcard) style, there will be one BSB per 
(session, PHOP) pair. 


For FF style, there will be one BSB per (session, 
filter_spec) pair. Note that an FF style RERR message 
carries only one flow descriptor. 


For SE style, there will be one BSB per (session, 
filter_spec), for each filter_spec contained in the 
filter spec list of the flow descriptor. 


2 For each BSB in the preceding step, set (or replace) 
its FLOWSPEC Qb with FLOWSPEC from the message, and 
set (or reset) its timer Tb to Kb*R seconds. If the 
BSB is new, set its PHOP value, and set its 
Sender_Template equal to the appropriate filter_spec 
from the message. 
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3. Execute the RESV REFRESH event sequence (shown below) 
for the previous hop PHOP, but only with the B_Merge 
flag off. That is, if processing in the RESV REFRESH 
sequence reaches the point of turning the B_Merge flag 
on (because all matching reservations are blockaded), 
do not turn it on but instead exit the REFRESH 
sequence and return here. 


o Execute the following for each RSB for this session whose 
OI differs from In If and whose Filter spec list has at 
least one filter spec in common with the FILTER SPEC“ in 
the RERR message. For WF style, empty FILTER SPEC“ 
structures are assumed to match. 


T; If Error_Code = 01 and the InPlace flag in the 
ERROR_SPEC is 1 and one or more of the BSB’s 
found/created above has a Qb that is strictly greater 
than Flowspec in the RSB, then continue with the next 
matching RSB, if any. 


2. If NHOP in the RSB is the local API, then: 


- If the FLOWSPEC in the RERR message is strictly 
greater than the RSB Flowspec, then turn on the 
NotGuilty flag in the ERROR SPEC. 


5 Deliver an error upcall to application: 


Call: <Upcall_Proc>( session-id, RESV_ERROR, 
Error_code, Error_value, 
Node_Addr, Error_flags, 
Flowspec, Filter_Spec_List 
[ , Policy_data] ) 


and continue with the next RSB. 


3i If the style has wildcard sender selection, use the 
SCOPE object SC.In from the RERR message to construct 
a SCOPE object SC.Out to be forwarded. SC.Out should 
contain those sender addresses that appeared in SC.In 
and that route to OI, as determined by scanning the 
PSB’s. If SC.Out is empty, continue with the next 
RSB. 


4. Create a new RERR message containing the error flow 
descriptor and send to the NHOP address specified by 
the RSB. Include SC.Out if the style has wildcard 
sender selection. 
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J; Continue with the next RSB. 
o Drop the RERR message and return. 
RESV CONFIRM ARRIVES 


o If the (unicast) IP address found in the RESV CONFIRM 
object in the RACK message matches an interface of the 
node, a confirmation upcall is made to the matching 
application: 


Call: <Upcall_Proc>( session-id, RESV CONFIRM, 
Error code, Error value, Node Addr, 
LUB-Used, nlist, Flowspec, 

Filter Spec List, NULL, NULL ) 


o Otherwise, forward the RACK message to the IP address in 
its RESV CONFIRM object. 


Drop the RACK message and return. 
UPDATE TRAFFIC CONTROL 


The sequence is invoked by many of the message arrival sequences 
to set or adjust the local traffic control state in accordance 
with the current reservation and path state. An implicit 
parameter of this sequence is the ‘active’ RSB. 


If the result is to modify the traffic control state, this 
sequence notifies any matching local applications with a 

RESV EVENT upcall. If the state change is such that it should 
trigger immediate RESV refresh messages, it also turns on the 
Resv Refresh Needed flag. 


o Compute the traffic control parameters using the following 
steps. 
1; Initially the local flag Is_Biggest is off. 
Pls Consider the set of RSB's matching SESSION and OI from 


the active RSB. If the style of the active RSB is 
distinct, then the Filter spec list must also be 
matched. 


= Compute the effective kernel flowspec, 
TC_Flowspec, as the LUB of the FLOWSPEC values in 
these RSB’s. 
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- Compute the effective traffic control filter spec 
(list) TC Filter Spec“ as the union of the 
Filter spec lists from these RSB's. 


- If the active RSB has a FLOWSPEC larger than all 
the others, turn on the Is Biggest flag. 


Scan all RSB's matching session and Filtss, for all 
OI. Set TC B Police flag on if TC Flowspec is smaller 
than, or incomparable to, any FLOWSPEC in those RSB’s. 


Locate the set of PSBs (senders) whose 
SENDER TEMPLATEs match Filter spec list in the active 
RSB and whose QutInterface list includes OI. 


Set TC E Police flag on if any of these PSBs have 
their E Police flag on. Set TC M Police flag on if it 
is a shared style and there is more than one PSB in 
the set. 


Compute Path Te as the sum of the SENDER TSPEC objects 
in this set of PSBs. 


o Search for a TCSB matching SESSION and OI, for distinct 


style 


(FF), it must also match Filter spec list. 


If none is found, create a new TCSB. 


o If TCSB is new: 
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Store TC Flowspec, TC Filter Spec“, Path Te, and the 
police flags into TCSB. 


Turn the Resv Refresh Needed flag on and make the 
traffic control call: 


TC AddFlowspec( OI, TC Flowspec, 


Path Te, police flags) 
-> Rhandle, Fwd Flowspec 


If this call fails, build and send a RERR message 
specifying "Admission control failed" and with the 
InPlace flag off. Delete the TCSB, delete any 

RESV CONFIRM object from the active RSB, and return. 
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4. Otherwise (call succeeds), record Rhandle and 
Fwd Flowspec in the TCSB. For each filter spec F in 
TC Filter Spec”, call: 


TC AddFilter( OI, Rhandle, Session, F) 
-> Fhandle 


and record the returned Fhandle in the TCSB. 


Otherwise, if TCSB is not new but no effective kernel 
flowspec TC Flowspec was computed earlier, then: 


I; Turn on the Resv_Refresh_Needed flag. 


2. Call traffic control to delete the reservation: 
TC_DelFlowspec( OI, Rhandle ) 

3: Delete the TCSB and return. 

Otherwise, if TCSB is not new but the TC Flowspec, Path Te, 

and/or police flags just computed differ from corresponding 


values in the TCSB, then: 


T; If the TC_Flowspec and/or Path_Te values differ, turn 
the Resv_Refresh_Needed flag on. 


2. Call traffic control to modify the reservation: 


TC_ModFlowspec( OI, Rhandle, TC_Flowspec, 
Path_Te, police_flags ) 
-> Fwd Flowspec 


3 If this call fails, build and send a RERR message 
specifying "Admission control failed" and with the 
InPlace bit on. Delete any RESV_CONFIRM object from 
the active RSB and return. 


aye Otherwise (the call succeeds), update the TCSB with 
the new values and save Fwd_Flowspec in the TCSB. 


If the TCSB is not new but the TC_Filter_Spec* just 
computed differs from the FILTER_SPEC* in the TCSB, then: 


La Make an appropriate set of TC DelFilter and 
TC AddFilter calls to transform the Filter spec list 
in the TCSB into the new TC Filter Spec”. 
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2s Turn on the Resv Refresh Needed flag. 


If the active RSB contains a RESV CONFIRM object, then: 


IG If the Is Biggest flag is on, move the RESV CONFIRM 
object into the TCSB and turn on the 
Resv Refresh Needed flag. (This will later cause the 
RESV REFRESH sequence to be invoked, which will either 
forward or return the RESV CONFIRM object, deleting it 
from the TCSB in either case). 


24 Otherwise, create and send a RACK message to the 
address in the RESV_CONFIRM object. Include the 
RESV_CONFIRM object in the RACK message. The RACK 
message should also include an ERROR_SPEC object whose 
Error_Node parameter is IP address of OI from the TCSB 
and that specifies "No Error". 


If the Resv_Refresh_Needed flag is on and the RSB is not 
from the API, make a RESV_EVENT upcall to any matching 
application: 


Call: <Upcall_Proc>( session-id, RESV_EVENT, 
style, Flowspec, Filter_spec_list [ , 
POLICY_DATA] ) 


where Flowspec and Filter_spec_list come from the TCSB and 
the style comes from the active RSB. 


Return to the event sequence that invoked this one. 


PATH REFRESH 


This sequence sends a path refresh for a particular sender, 


Eeey 


a PSB. This sequence may be entered by either the 


expiration of a refresh timer or directly as the result of the 
Path_Refresh_Needed flag being turned on during the processing 
of a received PATH message. 


o 


Insert TIME VALUES object into the PATH message being 
built. Compute the IP TTL for the PATH message as one less 
than the TIL value received in the message. However, if 
the result is zero, return without sending the PATH 
message. 


Create a sender descriptor containing the SENDER TEMPLATE, 
SENDER TSPEC, and POLICY DATA objects, if present in the 
PSB, and pack it into the PATH message being built. 
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o Send a copy of the PATH message to each interface OI in 
Out Interface list. Before sending each copy: 
ime If the PSB has the E_Police flag on and if interface 


OI is not capable of policing, turn the E_Police flag 
on in the PATH message being built. 


2. Pass the ADSPEC object and Non_RSVP flag present in 
the PSB to the traffic control call TC_Advertise. 
Insert the modified ADSPEC object that is returned 
into the PATH message being built. 


3 Insert into its PHOP object the interface address and 
the LIH for the interface. 


RESV REFRESH 


This sequence sends a reservation refresh towards a particular 
previous hop with IP address PH. This sequence may be entered 
by the expiration of a refresh timer, or invoked from the PATH 
MESSAGE ARRIVES, RESV MESSAGE ARRIVES, RTEAR MESSAGE ARRIVES, or 
RERR MESSAGE ARRIVES sequence. 


In general, this sequence considers each of the PSB's with PHOP 
address PH. For a given PSB, it scans the TCSBs for matching 
reservations and merges the styles, FLOWSPECs and 
Filter spec list's appropriately. It then builds a RESV message 
and sends it to PH. The details depend upon the attributes of 
the style(s) included in the reservations. 


Initially the Need Scope flag is off and the new SCOPE object is 
empty. 


o Create an output message containing INTEGRITY (if 
configured), SESSION, RSVP HOP, and TIME VALUES objects. 


o Determine the style for these reservations from the first 
RSB for the session, and move the STYLE object into the 
proto-message. (Note that the present set of styles are 
never themselves merged; if future styles can be merged, 
these rules will become more complex). 


o If style is wildcard and if there are PSB's from more than 
one PHOP and if the multicast routing protocol does not use 
shared trees, set the Need Scope flag on. 
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o Select each sender PSB whose PHOP has address PH. Set the 
local flag B Merge off and execute the following steps. 


Es 


Braden & Zhang 


Select all TCSB’s whose Filter_spec_list’s match the 
SENDER_TEMPLATE object in the PSB and whose OI appears 
in the OutInterface_list of the PSB. 


If the PSB is from the API, then: 


= If TCSB contains a CONFIRM object, then create 
and send a RACK message containing the object and 
delete the CONFIRM object from the TCSB. 


7 Continue with next PSB. 


If B Merge flag is off then ignore a blockaded TCSB, 
as follows. 


= Select BSB’s that match this TCSB. If a selected 
BSB is expired, delete it. If any of the 
unexpired BSB’s has a Qb that is not strictly 
larger than TC_Flowspec, then continue processing 
with the next TCSB. 


However, if steps 1 and 2 result in finding that all 
TCSB’s matching this PSB are blockaded, then: 


= If this RESV REFRESH sequence was invoked from 
RESV ERROR RECEIVED, then return to the latter. 


= Otherwise, turn on the B_Merge flag and restart 
at step 1, immediately above. 


Merge the flowspecs from this set of TCSB’s, as 
follows: 


= If B_Merge flag is off, compute the LUB over the 
flowspec objects. From each TCSB, use the 
Fwd_Flowspec object if present, else use the 
normal Flowspec object. 
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While computing the LUB, check for a RESV_CONFIRM 
object in each TCSB. If a RESV_CONFIRM object is 
found: 


= If the flowspec (Fwd_Flowspec or Flowspec) 
in that TCSB is larger than all other (non- 
blockaded) flowspecs being compared, then 
save this RESV_CONFIRM object for forwarding 
and delete from the TCSB. 


- Otherwise (the corresponding flowspec is not 
the largest), create and send a RACK message 
to the address in the RESV CONFIRM object. 
Include the RESV CONFIRM object in the RACK 
message. The RACK message should also 
include an ERROR_SPEC object whose 
Error_Node parameter is IP address of OI 
from the TCSB and specifying "No Error". 


- Delete the RESV CONFIRM object from the 
TCSB. 


Otherwise (B Merge flag is on), compute the GLB 
over the Flowspec objects of this set of TCSB’s. 


While computing the GLB, delete any RESV CONFIRM 
object object in any of these TCSB’s. 


(All matching TCSB’s have been processed). The next 


step depends upon the style attributes. 


Distinct reservation (FF) style 


Use the Sender_Template as the merged 
FILTER_SPEC. Pack the merged (FLOWSPEC, 
FILTER_SPEC, F_POLICY_DATA) triplet into the 
message as a flow descriptor. 


Shared wildcard reservation (WF) style 


There is no merged FILTER_SPEC. Merge (compute 
the LUB of) the merged FLOWSPECS from the TCSB’s, 


across all PSB’s for PH. 
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Shared distinct reservation (SE) style 


Using the Sender Template as the merged 

FILTER SPEC, form the union of the FILTER SPECS 
obtained from the TCSB’s. Merge (compute the LUB 
of) the merged FLOWSPECS from the TCSB's, across 
all PSB's for PH. 


If the Need Scope flag is on and the sender specified 
by the PSB is not the local API: 


= Find each RSB that matches this PSB, i.e., whose 
Filter_spec_list matches Sender_Template in the 
PSB and whose OI is included in 
OutInterface_list. 


= If the RSB either has no SCOPE list or its SCOPE 
list includes the sender IP address from the PSB, 
insert the sender IP address into new_SCOPE. 


(All PSB’s for PH have been processed). Finish the RESV 
message. 


Li 


If Need Scope flag is on but new SCOPE is empty, no 
RESV message should be sent, return. (Otherwise, if 
Need Scope is on, move new SCOPE into the message. 


If a shared reservation style is being built, move the 
final merged FLOWSPEC object and filter spec list into 
the message. 


If a RESV CONFIRM object was saved earlier, move it 
into the new RESV message. 


Set the RSVP HOP object in the message to contain the 
IncInterface address through which it will be sent and 
the LIH from (one of) the PSB's. 


Send the message to the address PH. 


ROUTE CHANGE NOTIFICATION 


This sequence is triggered when routing sends a route change 


o 


notification to RSVP. 


Each PSB is located whose SESSION matches the destination 
address and whose SENDER TEMPLATE matches the source 
address (for multicast). 
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T; If the OutInterface_list from the notification differs 
from that in the PSB, execute the PATH LOCAL REPAIR 
sequence. 

2. If the IncInterface from the notification differs from 


that in the PSB, update the PSB. 
PATH LOCAL REPATR 


The sequence is entered to effect local repair after a route 
change for a given PSB. 


o Wait for a delay time of W seconds. 
o Execute the PATH REFRESH event sequence (above) for the 
PSB: 
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Security Considerations 


Processing the RSVP INTEGRITY object [Baker96] is only mentioned in 
this memo, because the processing rules are described here only in 
general terms. The RSVP support for IPSEC [RFC 2207] will imply 
modifications that have not yet been incorporated into these 
processing rules. 
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